TT-16964 - remove sbom job from release workflow#962
Conversation
The sbom job was requesting 'id-token: write' permission but the workflow-level permissions only grant 'id-token: none', causing the workflow validation to fail with: Error calling workflow '...sbom.yaml': The nested job 'sbom' is requesting 'id-token: write', but is only allowed 'id-token: none'. Removing the sbom job resolves the validation error. Refs: TT-16964 Signed-off-by: bsten-tyk <221599321+bsten-tyk@users.noreply.github.com>
Security Issues (4)
Security Issues (4)
Performance Issues (1)
Quality Issues (1)
Powered by Visor from Probelabs Last updated: 2026-04-14T10:57:19.403Z | Triggered by: pr_updated | Commit: c2444a0 💡 TIP: You can chat with Visor using |
|
This PR addresses critical failures in the While the PR successfully unblocks the pipelines, it introduces significant side effects. The removal of the Files Changed Analysis
Architecture & Impact Assessment
graph TD
subgraph "Release Workflow (Before)"
A[goreleaser] --> B{sbom job};
B --x|"Fails due to id-token permission error"| C[Workflow Failure];
end
subgraph "Release Workflow (After)"
D[goreleaser] --> E[Release Succeeds];
F((No SBOM Generated));
E --> F;
end
Scope Discovery & Context Expansion
Metadata
Powered by Visor from Probelabs Last updated: 2026-04-14T10:57:26.728Z | Triggered by: pr_updated | Commit: c2444a0 💡 TIP: You can chat with Visor using |
The security hardening commit 339740c changed 'go install' to 'go run' for goimports, which only executes it once without installing the binary. This caused ci-test.sh to fail with 'goimports: command not found' since the binary was never placed on PATH. Using 'go install' with a pinned version (@v0.33.0) satisfies both the security requirement (pinned, not @latest) and the functional requirement (binary available for ci-test.sh). Refs: TT-16964 Signed-off-by: bsten-tyk <221599321+bsten-tyk@users.noreply.github.com>
gotestsum@v1.12.1 depends on golang.org/x/tools@v0.24.0 which is incompatible with Go 1.25 (invalid array length -delta * delta in tokeninternal.go:64). Upgrading to gotestsum@v1.13.0 pulls in golang.org/x/tools@v0.36.0 which compiles cleanly. Refs: TT-16964 Signed-off-by: bsten-tyk <221599321+bsten-tyk@users.noreply.github.com>
The security hardening commit 339740c pinned base images to SHA256 digests, but used single-platform (amd64-only) digests instead of multi-platform manifest list digests. This breaks multi-arch Docker builds because arm64/s390x build stages pull the amd64-only base image. Replace with manifest list digests that cover all required platforms: - debian:trixie-slim: amd64, arm64, s390x, and others - gcr.io/distroless/static-debian12:nonroot: amd64, arm64, s390x, ppc64le Verified via: docker buildx imagetools inspect <image> Refs: TT-16964 Signed-off-by: bsten-tyk <221599321+bsten-tyk@users.noreply.github.com>
| RUN dpkg -i /${BUILD_PACKAGE_NAME}_*${TARGETARCH}.deb && rm /*.deb | ||
|
|
||
| FROM gcr.io/distroless/static-debian12:nonroot@sha256:5074667eecabac8ac5c5d395100a153a7b4e8426181cca36181cd019530f00c8 | ||
| FROM gcr.io/distroless/static-debian12:nonroot@sha256:a9329520abc449e3b14d5bc3a6ffae065bdde0f02667fa10880c49b35c109fd1 |
There was a problem hiding this comment.
I don't think we can add sha here, we depend on this step to get the latest debian security fix during the build time for all our releases.
If we pin to a sha here, it would break this workflow, and we'll no longer get security fixes, unless we update the image digests for every release, and all our CVE timelines/SLAs for debian fixes would break.
I think it could work with an associated workflow with dependabot or digestabot to update digests, but these PRs should still be approved, merged and picked to the right branches to get the latest updates.
Until we have such similar steps set up in practice, I don't think we can use sha pinning here, and will have to accept this risk, and trust google/debian that the upstream images pulled using tags are safe.
There was a problem hiding this comment.
okay, updated tags in c2444a0 based on your suggestion.
SHA pinning base images prevents automatic Debian security patch updates from flowing through. Without automated digest bumping (dependabot/digestabot), pinned digests will fall behind on CVE fixes. Revert to unpinned tags matching the tyk gateway project and gromit-generated templates. Refs: TT-16964 Signed-off-by: bsten-tyk <221599321+bsten-tyk@users.noreply.github.com>
|
| RUN dpkg -i /${BUILD_PACKAGE_NAME}_*${TARGETARCH}.deb && rm /*.deb | ||
|
|
||
| FROM gcr.io/distroless/static-debian12:nonroot@sha256:5074667eecabac8ac5c5d395100a153a7b4e8426181cca36181cd019530f00c8 | ||
| FROM gcr.io/distroless/static-debian12:nonroot |
There was a problem hiding this comment.
We can move to debian 13 here, as with nonroot static images, there shouldn't be no issue with bumping debian version. (No GLIBC)
|
/release to release-5.8 |




Description
This PR fixes three CI/CD issues introduced by commit 339740c ("security: pin actions to SHA, harden CI permissions, pin Docker images" #956) that have broken both the
ci-test.ymlandrelease.ymlworkflows on master since April 1, 2026.Changes:
Remove
sbomjob fromrelease.yml-- Thesbomjob calls a reusable workflow that requestsid-token: write, but the workflow-levelpermissionsblock only grantscontents: read. This caused all release workflow runs on master to fail withstartup_failure.Fix
goimportsinstall inci-test.yml-- The security hardening changedgo installtogo runfor goimports.go runexecutes the tool once but does not install the binary to PATH, causingci-test.shto fail with "goimports: command not found". Restored togo installwith a pinned version (@v0.33.0).Fix multi-platform manifest digests in
Dockerfile.distroless-- Base images were pinned to single-platform (amd64-only) SHA256 digests instead of multi-platform manifest list digests. This broke arm64 and s390x Docker builds becausedpkgrejected architecture mismatches. Replaced with manifest list digests that cover all required platforms.Related Issue
TT-16964
Motivation and Context
Both CI workflows (
ci-test.ymlandrelease.yml) have been broken on master since April 1, 2026 due to unintended side effects from the security hardening commit. No successful release workflow run has occurred since March 26. This PR restores CI functionality while preserving the security intent (pinned versions and digests).How This Has Been Tested
sbompermission error is a workflow validation failure at parse time -- removing the job eliminates it.goimportsfix was verified by analyzing the CI failure logs showing "command not found" atci-test.sh:33.docker buildx imagetools inspectto confirm manifest list digests cover amd64, arm64, and s390x platforms.Screenshots (if appropriate)
N/A
Types of changes
Checklist
masterbranch (left side).go fmt -sgo vet